(レポート)[ServerlessConf London] 「 Globally Available Serverless Architectures」 #serverlessconf

はじめに

本レポートは2016年10月27日(木)〜28日(金)に開催されたServerlessConf Londonのセッション"Globally Available Serverless Architectures"のレポートです。

発表資料

動画

なし

発表スライド

発表スライド

概要

テーマはサービスをグローバルに展開するときに気をつけるべきことは何か? 前半では課題や留意点が述べられ、後半ではサーバーレスアーキテクチャーでの解決方法が述べられています。

スピーカーの Rich Jones さんは Python のサーバーレスフレームワーク Zappa の作者ということもあり、後半では Zappa と AWS を前提に話が進みます。

グローバルサービスで注意すべきこと

1:Speed

サービスをUS内のリージョンで構築する場合、アメリカ国内の通信のレイテンシーは無視できる程度だが、東京との間では数百ミリセカンドにもなる。

地球上で物理的に離れたところから利用するユーザーもいることを意識すること。

2 Scalability

リージョンあたりのリクエスト処理能力の上限があっても、全リージョンにデプロイすれば、そのリージョンの数の倍だけ処理能力も増える

3:Redundancy

AWS も障害が発生しないわけではない インスタンスや特定のリージョンでサービス障害が発生するかもしれないが、全リージョンが全滅することはありえない 複数リージョンにデプロイしてリスクヘッジする

4:Security

会社の規定、物理インフラ、仮想インフラ、サーバー上など様々なコンポーネントがある 社内・社外の両方から脅威にさらされている

5: Regulatory compliance!

国によって法制度がことなる。 個人情報・金融・医療データはややこしいわかりやすい例

• アメリカのHIPAA
• EU圏のデータ保護規則
• PCI

などなど、準拠すべきコンプライアンスがある

ここまでのまとめ

同じ製品でも国によって準拠すべきコンプライアンスは異なる

Zappa/AWSを使ったサーバーレスアーキテクチャーでの解決

Zappa とは

• Api Gateway
• Lambda

をベースにしたサーバーレスフレームワーク。

スピーカーの Rich Jones が作者

アーキテクチャーの違い

従来:サーバーを常時起動し、各リクエストをWebアプリが処理 Zappa:API Gatewayを起動し、各リクエストに対してサーバーを起動し、Webアプリが処理。処理が終わったらサーバーは破棄。

後者ではリクエストとサーバーの数が同じ

サーバー運用費が劇的に下がる。

Zappa は WSGI ベースの Python アプリがターゲット。 WSGIベースのウェブアプリケーションであれば、ほぼコード修正なしにサーバーレスアーキテクチャーで実行できる

チャットやシンプルなAPIサーバといった小さなシステムだけでなく、Djangoで書かれたCMSのような重厚なシステムにも対応している。

Case study A: Globally Available API Microservice

世界中のどこからでも 200ms 以内にリクエストした人の緯度経度を返す。 メインロジックは数行

Flaskベースのアプリをサクッと Zappa に移行 ベータ機能ではあるがAWSの全リージョンにデプロイ可能

世界中のリージョンにデプロイしたサービスのルーティングについて

ルーティング

クライアントからはどの通信経路でアプリにリクエストさせるのか?

1 Simple, Stupid

方針:地域ごとに特定のホストにアクセスさせる 所見:ユーザーはそんなめんどいことはやりたくない

2 Latency

方針:通信の近さで振り分ける 所見:通信は早いが、コンプライアンスを無視してしまう。

3 Geolocation

方針:IPでエリアを特定し振り分ける 所見:コンプライアンスを満たすが、通信が遅くなる

4 Round Robin

方針:同じエリア内限定でラウンドロビンする 所見:負荷分散出来るが、通信が遅くなる

静的コンテンツであれば、CDN を使うとレイテンシーは下がる

Case study B: Globally Distributed Medical Service

コンプライアンスがうるさい医療データ処理システムをグローバル展開するにはどうすればよいか?

ハイブリッドアーキテクチャー

• HTTP(AWS API)/非HTTP(ファイル操作)の混在
• 永続化される(S3)/されない(API GW/SQS)インフラの混在

アーキテクチャー

Medical Data -> S3 -> Lambda -> SQS S3 -> Lambda -> SNS -> Doctor

永続インフラについて

満たすべきは以下

• セキュア
• 永続化される
• コンプライアンスに準拠

データベースが不要なシステムというのは極めて稀 データベースがある場合はどうすればよいのか?

データの管理方針

認証データ

• 中央に集約
• レプリカを各リージョンに展開
• ログインなどはローカルのレプリカを参照するのではやい
• 中央への書き込み時のみ遅い

医療データ

• 中央集約しない
• 各リージョン内に完結してデータ管理

まとめ

Zappa を使うと

• 時間を節約し
• 低コストに
• グローバル展開するサービス

をデプロイ出来ます。

感想

楽しめるトークでありながら、何故か動画がYouTubeに公開されていません。

撮影のトラブルによるものであり、インターネットに公開するとまずいことを発言したわけではないと思います。